Portals provide end users with unified access to content, applications, and collaboration services in a highly personalized manner. An example is IBM's WebSphere Portal which provides a middleware framework and tools for building and managing portals using component applications called “portlets”.
Typically, a portal employs an architecture where the portal itself only implements standard functionality like authentication, state handling, aggregation, caching, user management, etc., and provides the infrastructure for application components. This architecture includes APIs for the integration of applications so that applications from different partners can be used as long as they match the portal product's API. In the portal environment, these applications are typically called portlets.
Portlets are pluggable components that can be added to portals and are designed to run inside a portal's portlet container. Portlets may provide different functions ranging from simple rendering of static or dynamic content to application functions such as e-mail, calendar, etc. Portlets are invoked indirectly via the portal application and produce content that is suited for aggregation in larger pages, e.g., portlets should produce mark-up fragments adhering guidelines that assure that the content generated by different portlets can be aggregated into one page. Typically, portlets run on a portal server, processing input data and rendering content locally.
FIG. 1 provides a schematic system view of a web server implementing such a prior art portal.
A portal is typically implemented on a network server, for example a web server 100, which includes various logic components for user authentication 105, state handling 110, and aggregation 170 of fragments. The web server 100 further includes a plurality of portlets 120 provided in respective pages 125, with a respective plurality of APIs 130 to a respective portlet container software 135 for setting the pages 125 into a common web page context, and some portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required.
A portal engine of the web server 100 in FIG. 1 implements an aggregation of portlets 120 based on an underlying portal model 150 and portal information such as security settings, user roles, customization settings, and device capabilities. Within a rendered page 125, the portal automatically generates the appropriate set of navigation elements based on the portal model 150. The portal engine invokes portlets 120 during the aggregation as required and when required and uses caching to reduce the number of requests made to the portlets 120.
The portal model 150 represents the portal's content structure, i.e., the hierarchical structure of portal pages 125, which may again contain nested pages, and portlets 120, which are arranged on pages. This data is stored in a portal database 128 in an adequate representation based on prior art techniques such as relational tables.
Web clients interact with portlets 120 via a request/response paradigm implemented by the portal. Usually, users interact with content produced by portlets 120 by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which are then forwarded to the portlets targeted by the user's interactions.
Accordingly, the portal waits for client requests and responds to these requests. A client request message includes an URL/URI which addresses the requested page.
The aggregation logic 170 includes all steps that are required to assemble a page 125 that is sent back to the client. Typically, these steps include loading the portal model 150 from the portal database 128, traversing the portal model 150, and calling the instances referenced in the portal model 150 in order to obtain their output, which is assembled to a single page 125. The portal model 150 may be defined as the relationship as well as the arrangement of the components that are used to create the visual representation of the content. The portal model 150 can be defined through a manual layout interface 160 by administrators or users and saved in the portal database 128.
One activity in the rendering and aggregation processes is the generation of URLs that address portal pages 125. An URL is generated by the aggregation logic 170 and includes coded state information.
By including the state information in an URL, the portal ensures that it is later able to establish the navigation and presentation context when the client sends a request for this URL.
The portlet container 135 is a single control component competent for all portlets 120, which may control the execution of code residing in each of the portlets 120. The portlet container 135 provides a runtime environment for the portlets 120 and the facilities required for event handling, inter-portlet messaging, and access to portlet instance and configuration data, etc. The portal resources 140 include the portlets 120 themselves and the pages 125, on which the portlets 120 are aggregated in form of an aggregation of fragments. The portal database 128 stores the portlet description, which includes the portlet identifier, and which includes attributes such as portlet name, portlet description, portlet title, portlet short title, and keywords.
Referring now to FIG. 2B, there is illustrated a diagram of a portal server with focus on portal interaction flow.
In the main processing flow of a portal, a request is sent to the server where it is processed and answered. The first step in processing a request is to verify that the sender is authenticated to interact with the server, see step 310. The result of this verification influences the response of the server; if the sender is not correctly authenticated the request may be denied or the sender is prompted to provide credentials.
As a second step 320, the navigational state, which represents the state of portal resources for a particular request, is deserialized and prepared for modification or for again serializing the navigational state into URLs. Among other information, the navigational state contains at least the identification of the requested page.
Navigational state may contain actions which are to be executed when a request transporting this state is sent to the portal. This is done in the action processing phase, step 330, which executes the encoded actions. These actions may modify server-side state, resources that can be managed through portal and/or influence the generation of the response.
Finally, the response is generated in the aggregation phase 340 based on the navigational state valid for the request by aggregating markup from different sources and writing the combined output to the response. During the aggregation phase, the set of portlets to be invoked according to the navigational state is determined (i.e., the set of portlets that are arranged on the requested page) and each portlet is invoked by issuing a request to the portlet container (see FIG. 2A, renderPortlet( ) requests). This request contains the identification of the portlet as well as the portlet state.
The portlet container prepares the portlet context according to portlet ID and portlet state included in or referenced by the renderPortlet( ) request. This may require reading and processing the portlet definition from the portal database. Then, the portlet container invokes the portlet providing the portlet context (see FIG. 2A, render( ) requests). The portlet container accepts the markup fragment generated by the portlet. After this, processing of the request ends, step 350.
Referring again to FIG. 1, portlet deployment 180 allows an administrator to deploy portlets 120. The portlet deployment 180 accepts an external representation of a portlet 120, e.g., a portlet application in the form of an application archive, and stores the portlet resources such as code, jsp files, html files, etc., either in the portal database 128 or in a repository of an underlying application server or web server. In addition it stores the portlet definition of the portlets 120 contained in the portlet application in the portal database 128.
Using the manual layout interface 160, a user or an administrator may modify the portal model 150, i.e., the content structure, e.g., by creating new pages 125, modifying pages 125, and arranging portlets 120 on pages 125. The manual layout interface 160 stores these changes in the portal database 128.
A prior art portal such as that described above realizes a binding of portlets, which is fixed during deployment in case of a local portlet or by configuration for the case of a remote portlet. This is insufficient in regard to flexibility and selectivity when satisfying the needs of web portal visitors. As such, it is desirable to have portal architectures offering more flexibility and selectivity when providing portlets to portal visitors.